In a client-server environment clients often cache data that is owned by the server. The client stores a copy of data from the server on memory, (e.g., random access memory (RAM), such as local RAM, or any other place data could be stored, such as local hard disks or flash memory devices) which is coupled to the client. The client can therefore access and modify this cached data locally without requiring communication across a network or other communication channel for accessing the data remotely at the server. File systems like the Windows NTFS file system support multiple data streams per file. Oplocks requests are made on stream handles or file handles (e.g, open/create of the file). Clients also have the ability to cache file handles so that the same handle can be re-used at a later time. For example, current operating system platforms provide four types of oplocks as follows: (1) Level 2 Oplocks (or read caching oplocks) for clients to be able to safely cache data that they read from the file system; (2) Exclusive Oplocks (or, read and write caching oplocks) for clients to be able to safely cache reads and writes, and flush modified data to the file system; (3) Batch Oplocks (or, read and write and handle caching oplocks) for clients to be able to safely cache reads and writes as well as open handles; (4) Filter Oplocks for applications/filters which read and write file data to “back out” when some other application/client tries to access the same file. The type of oplock indicates the multiple caching intents associated with the contemplated nature of remote access to fields hosted on a network server.
Opportunistic locks (or oplocks in short.) provide a mechanism to enforce distributed cache coherency when multiple entities operate on a single data stream. Opportunistic locks also provide a mechanism for clients to cache file handles without being intrusive and blocking other clients from getting access to the file. The system therefore uses methods to prevent clients from interrupting access to files among each other, such as by opportunistic locking mechanisms (oplocks). For example, the server may temporarily cause a new client to wait for the existing client (who is caching server data) to flush cached data (e.g., sending cached, modified data back from the client to the server) and cause the data on the server to be consistent, before allowing the new client access to the data.
Oplocks as they are currently defined, expose very rigid semantics and do not provide the intended caching & synchronization behavior when working with modern applications. There is a need therefore to provide adequate flexibility with oplock mechanisms in accord with work intentions in specific client environments.